<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
	<title>限制内存使用 | Elasticsearch: 权威指南 | Elastic</title>
    <!-- Give IE8 a fighting chance -->
    <!--[if lt IE 9]>
    <script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
    <script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
    <![endif]-->
	<link rel="stylesheet" type="text/css" href="../static/styles.css" />
</head>
<body>
<div class="main-container">
    <section id="content">
        
        <div class="content-wrapper">
            <section id="guide" lang="zh_cn">
                <div class="container">
                    <div class="row">
                        <div class="col-xs-12 col-sm-8 col-md-8 guide-section">
                            <div style="color:gray; word-break: break-all; font-size:12px;">原文地址: <a href="https://www.elastic.co/guide/cn/elasticsearch/guide/current/_limiting_memory_usage.html" rel="nofollow">https://www.elastic.co/guide/cn/elasticsearch/guide/current/_limiting_memory_usage.html</a>, 版权归 www.elastic.co 所有<br/>
                            英文版地址: <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html" rel="nofollow">https://www.elastic.co/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html</a>
                            </div>
                        <!-- start body -->
                  <div class="page_header">
<b>请注意:</b><br>本书基于 Elasticsearch 2.x 版本，有些内容可能已经过时。
</div>
<div id="content">
<div class="breadcrumbs">
<span class="breadcrumb-link"><a href="index.html">Elasticsearch: 权威指南</a></span>
»
<span class="breadcrumb-link"><a href="aggregations.html">聚合</a></span>
»
<span class="breadcrumb-link"><a href="docvalues-and-fielddata.html">Doc Values and Fielddata</a></span>
»
<span class="breadcrumb-node">限制内存使用</span>
</div>
<div class="navheader">
<span class="prev">
<a href="aggregations-and-analysis.html">« 聚合与分析</a>
</span>
<span class="next">
<a href="_fielddata_filtering.html">Fielddata 的过滤 »</a>
</span>
</div>
<div class="section">
<div class="titlepage"><div><div>
<h2 class="title">
<a id="_limiting_memory_usage"></a>限制内存使用<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/edit/cn/300_Aggregations/100_circuit_breaker_fd_settings.asciidoc">edit</a>
</h2>
</div></div></div>
<p>一旦analyzed字符串被加载到 fielddata ，他们会一直在那里，直到被淘汰（或者节点崩溃）。由于这个原因，留意内存的使用情况、了解它是如何以及何时加载的、怎样限制对集群的影响是很重要的。</p>

<p>fielddata 是 <em>延迟</em> 加载的。如果你从来没有聚合一个analyzed字符串，就不会加载 fielddata 到内存中。此外，fielddata 是基于字段加载的，
这意味着只有很活跃地使用字段才会增加 fielddata 的负担。</p>

<p>然而，这里有一个令人惊讶的地方。假设你的查询是高度选择性和只返回命中的 100 个结果。大多数人认为 fielddata 只加载 100 个文档。</p>

<p>实际情况是，fielddata 会加载索引中（针对该特定字段的） <span class="strong strong"><strong>所有的</strong></span> 文档，而不管查询的特异性。逻辑是这样：如果查询会访问文档 X、Y 和 Z，那很有可能会在下一个查询中访问其他文档。</p>

<p>与 doc values 不同，fielddata 结构不会在索引时创建。相反，它<b>是在查询请求被执行时动态填充的</b>。这可能是一个比较复杂的操作，可能需要一些时间。
将所有的信息一次加载，再将其维持在内存中的方式要比反复只加载一部分 fielddata 的代价要低。</p>

<p>JVM 堆 资源有限，应该被合理利用。
限制 fielddata 对堆使用的影响有多套机制，这些限制方式非常重要，因为堆栈的乱用会导致节点不稳定（归因于缓慢的垃圾回收机制），甚至导致节点宕机（通常伴随 OutOfMemory 异常）。</p>
<div class="sidebar">
<div class="titlepage"><div><div>
<p class="title"><strong>选择堆大小（Choosing a Heap Size）</strong></p>
</div></div></div>
<p>在设置 Elasticsearch 堆大小时需要通过  <code class="literal">$ES_HEAP_SIZE</code> 环境变量应用两个规则：</p>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
不要超过可用 RAM 的 50%
</span>
</dt>
<dd>
Lucene 能很好地利用(由系统内核管理的)文件系统缓存。如果没有足够的文件系统缓存空间，性能会受到影响。
此外，专用于堆的内存越多意味着其他所有使用 doc values 的字段内存越少。
</dd>
<dt>
<span class="term">
不要超过 32 GB
</span>
</dt>
<dd>
如果堆大小小于 32 GB，JVM 可以利用指针压缩，这可以大大降低内存的使用：每个指针 4 字节而不是 8 字节。
</dd>
</dl>
</div>
<p>更详细和更完整的堆大小讨论，请参阅 <a class="xref" href="heap-sizing.html" title="堆内存:大小和交换">堆内存:大小和交换</a></p>
</div>
<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="fielddata-size"></a>Fielddata的大小<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/edit/cn/300_Aggregations/100_circuit_breaker_fd_settings.asciidoc">edit</a>
</h3>
</div></div></div>
<p><code class="literal">indices.fielddata.cache.size</code>  控制了给 fielddata 分配的堆空间大小。
当你发起查询时，如果这些字符串之前没有被加载过，analyzed字符串的聚合将会被加载到 fielddata。如果结果中 fielddata 大小超过了指定 <code class="literal">大小(size)</code> ，其他的值将会被回收从而获得空间。</p>
<p>默认情况下，设置都是 <em>不限制(unbounded)</em> ，Elasticsearch 永远都不会从 fielddata 中回收数据。</p>
<p>这个默认设置是刻意选择的：fielddata 不是临时缓存。它是驻留内存里的数据结构，必须可以快速执行访问，而且构建它的代价十分高昂。如果每个请求都重载数据，性能会十分糟糕。</p>
<p>一个有界的大小会强制数据结构淘汰数据。我们会看何时应该设置这个值，但请首先阅读以下警告：</p>
<div class="warning admon">
<div class="icon"></div>
<div class="admon_content">
<p>这个设置是一种保护措施，而非内存不足的解决方案。</p>
<p>如果没有足够空间可以将 fielddata 保留在内存中，Elasticsearch 就会时刻从磁盘重载数据，并淘汰其他数据以获得更多空间。内存的淘汰机制会导致重度磁盘I/O，并且在内存中生成很多垃圾，这些垃圾必须在晚些时候被回收掉。</p>
</div>
</div>
<p>设想我们正在对日志进行索引，每天使用一个新的索引。通常我们只对过去一两天的数据感兴趣，尽管我们会保留老的索引，但我们很少需要查询它们。不过如果采用默认设置，旧索引的 fielddata 永远不会从缓存中回收！
fieldata 会保持增长直到 fielddata 发生断熔（请参阅 <a class="xref" href="_limiting_memory_usage.html#circuit-breaker" title="断路器">断路器</a>），这样我们就无法载入更多的 fielddata。</p>

<p>这个时候，我们被困在了死胡同。但我们仍然可以访问旧索引中的 fielddata，也无法加载任何新的值。相反，我们应该淘汰旧的数据，并为新值获得更多空间。</p>

<p>为了防止发生这样的事情，可以通过在 <code class="literal">config/elasticsearch.yml</code> 文件中增加配置为 fielddata 设置一个上限：</p>
<div class="pre_wrapper lang-yaml">
<pre class="programlisting prettyprint lang-yaml">indices.fielddata.cache.size:  20% <a id="CO218-1"></a><i class="conum" data-value="1"></i></pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO218-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>可以设置堆大小的百分比，也可以是某个值，例如： <code class="literal">5gb</code> 。</p>
</td>
</tr>
</table>
</div>
<p>有了这个设置，最近最少使用(LRU: least recently used)的 fielddata 会被淘汰, 为新数据腾出空间。</p>
<div class="warning admon">
<div class="icon"></div>
<div class="admon_content">
<p>你可能会在在线文档中看到另外一个设置： <code class="literal">indices.fielddata.cache.expire</code> 。</p>
<p>这个设置 <em>永远都不会</em> 被使用！它很有可能在不久的将来被弃用。</p>
<p>这个设置要求 Elasticsearch 淘汰那些 <code class="literal">过期</code> 的 fielddata，不管这些值有没有被用到。</p>
<p>这对性能是件 <em>很糟糕</em> 的事情。淘汰内存数据 是有成本的，这种目的性的<em>周期性</em>的淘汰，却不会有任何回报。</p>
<p>没有理由使用这个设置：我们不能从理论上假设一个有用的情形。目前，它的存在只是为了向前兼容。我们只在很有以前提到过这个设置，但不幸的是网上各种文章都将其作为一种性能调优的小窍门来推荐。</p>
<p>它不是。永远不要使用！</p>
</div>
</div>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="monitoring-fielddata"></a>监控 fielddata（Monitoring fielddata）<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/edit/cn/300_Aggregations/100_circuit_breaker_fd_settings.asciidoc">edit</a>
</h3>
</div></div></div>
<p>无论是紧盯着 fielddata 的内存使用情况， 还是看有无数据被淘汰都十分重要。高淘汰数量可以预示严重的资源问题以及性能不佳的原因。</p>
<p>Fielddata 的使用可以被监控：</p>
<div class="ulist itemizedlist">
<ul class="itemizedlist">
<li class="listitem">
<p>按索引, 使用 <a href="http://www.elastic.co/guide/en/elasticsearch/reference/current/indices-stats.html" class="ulink" target="_top"><code class="literal">indices-stats</code> API</a> ：</p>
<div class="pre_wrapper lang-json">
<pre class="programlisting prettyprint lang-json">GET /_stats/fielddata?fields=*</pre>
</div>
</li>
<li class="listitem">
<p>按节点, 使用 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.6/cluster-nodes-stats.html" class="ulink" target="_top"><code class="literal">nodes-stats</code> API</a> ：</p>
<div class="pre_wrapper lang-json">
<pre class="programlisting prettyprint lang-json">GET /_nodes/stats/indices/fielddata?fields=*</pre>
</div>
</li>
<li class="listitem">
按索引节点：
</li>
</ul>
</div>
<div class="pre_wrapper lang-json">
<pre class="programlisting prettyprint lang-json">GET /_nodes/stats/indices/fielddata?level=indices&amp;fields=*</pre>
</div>
<p>使用设置 <code class="literal">?fields=*</code> ，可以将内存使用分配到每个字段。</p>
</div>

<div class="section">
<div class="titlepage"><div><div>
<h3 class="title">
<a id="circuit-breaker"></a>断路器 (Circuit Breaker)<a class="edit_me edit_me_private" rel="nofollow" title="Editing on GitHub is available to Elastic" href="https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/edit/cn/300_Aggregations/100_circuit_breaker_fd_settings.asciidoc">edit</a>
</h3>
</div></div></div>
<p>精明的读者可能已经发现 fielddata 大小设置的一个问题。fielddata 大小是在数据加载 <em>之后</em> 检查的。
如果一个查询试图加载比可用内存更多的信息到 fielddata 中会发生什么？答案很丑陋：你会收到 内存溢出异常(OutOfMemoryException) 。</p>

<p>Elasticsearch 包括一个 <em>fielddata 断熔器</em> ，这个设计就是为了处理上述情况。
断熔器通过内部检查（字段的类型、基数、大小等等）来估算一个查询需要的内存。它然后检查要求加载的 fielddata 是否会导致 fielddata 的总量超过堆的配置比例。</p>
<p>如果估算查询的大小超出限制，就会 <em>触发</em> 断路器，查询会被中止并返回异常。这都发生在数据加载 <em>之前</em> ，也就意味着不会引起 内存溢出异常(OutOfMemoryException) 。</p>
<div class="sidebar">
<div class="titlepage"><div><div>
<p class="title"><strong>可用的断路器</strong></p>
</div></div></div>
<p>Elasticsearch 有一系列的断路器，它们都能保证内存不会超出限制：</p>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
<code class="literal">indices.breaker.fielddata.limit</code>
</span>
</dt>
<dd>
<code class="literal">fielddata</code> 断路器默认设置堆的 60% 作为 fielddata 大小的上限。
</dd>
<dt>
<span class="term">
<code class="literal">indices.breaker.request.limit</code>
</span>
</dt>
<dd>
<code class="literal">request</code> 断路器估算需要完成其他请求部分的结构大小，例如创建一个聚合桶，默认限制是堆内存的 40%。
</dd>
<dt>
<span class="term">
<code class="literal">indices.breaker.total.limit</code>
</span>
</dt>
<dd>
<code class="literal">total</code> 覆盖 <code class="literal">request</code> 和 <code class="literal">fielddata</code> 断路器, 保证两者组合起来不会使用超过堆内存的 70%。
</dd>
</dl>
</div>
</div>
<p>断路器的限制可以在文件 <code class="literal">config/elasticsearch.yml</code> 中指定，可以动态更新一个正在运行的集群：</p>
<div class="pre_wrapper lang-js">
<pre class="programlisting prettyprint lang-js">PUT /_cluster/settings
{
  "persistent" : {
    "indices.breaker.fielddata.limit" : "40%" <a id="CO219-1"></a><i class="conum" data-value="1"></i>
  }
}</pre>
</div>
<div class="calloutlist">
<table border="0" summary="Callout list">
<tr>
<td align="left" valign="top" width="5%">
<p><a href="#CO219-1"><i class="conum" data-value="1"></i></a></p>
</td>
<td align="left" valign="top">
<p>这个限制是按堆(heap)内存大小的百分比设置的。</p>
</td>
</tr>
</table>
</div>
<p>最好为断路器设置一个相对保守点的值。 记住 fielddata 需要与 <code class="literal">request</code> 断路器共享堆内存、索引缓冲内存和过滤器缓存。Lucene 的数据被用来构造索引，以及各种其他临时的数据结构。
正因如此，它默认值非常保守，只有 60% 。过于乐观的设置可能会引起潜在的 内存溢出(OOM) 异常，这会使整个节点宕掉。</p>
<p>另一方面，过度保守的值只会返回查询异常，应用程序可以对异常做相应处理。异常比服务器崩溃要好。这些异常应该也能促进我们对查询进行重新评估：为什么单个查询需要超过堆内存的 60% 之多？</p>
<div class="tip admon">
<div class="icon"></div>
<div class="admon_content">
<p>在 <a class="xref" href="_limiting_memory_usage.html#fielddata-size" title="Fielddata的大小">Fielddata的大小</a> 中，我们提过关于给 fielddata 的大小加一个限制，从而确保旧的无用 fielddata 被回收的方法。 <code class="literal">indices.fielddata.cache.size</code> 和 <code class="literal">indices.breaker.fielddata.limit</code> 之间的关系非常重要。
如果断路器的限制低于缓存大小，没有数据会被回收。为了能正常工作，断路器的限制 <em>必须</em> 要比缓存大小要高。</p>
</div>
</div>
<p>值得注意的是：断路器是根据总 堆内存大小 估算查询大小的，而 <em>非</em> 根据实际堆内存的使用情况。
这是由于各种技术原因造成的（例如，堆可能看上去是满的但实际上可能只是在等待垃圾回收，这使我们难以进行合理的估算）。但作为终端用户，这意味着设置需要保守，因为它是与 总堆内存 比较的，而 <em>不是</em> 可用堆内存。
</p>
</div>

</div>
<div class="navfooter">
<span class="prev">
<a href="aggregations-and-analysis.html">« 聚合与分析</a>
</span>
<span class="next">
<a href="_fielddata_filtering.html">Fielddata 的过滤 »</a>
</span>
</div>
</div>

                  <!-- end body -->
                        </div>
                        <div class="col-xs-12 col-sm-4 col-md-4" id="right_col">
                        
                        </div>
                    </div>
                </div>
            </section>
        </div>
    </section>
</div>
<script src="../static/cn.js"></script>
</body>
</html>